            *      *               *     *                    *
            **     *               **   **                    *
            * *    *          *    * * * *        *       *   *
            *  *   *   ***  *****  *  *  *   ***  ****  ***** ****
            *   *  *  *   *   *    *     *  *   * *   *   *   *   *
            *    * *  *****   *    *     *  *   * *   *   *   *   *
            *     **  *       *    *     *  *   * *   *   *   *   *
            *      *   ****   *    *     *   ***  *   *   *   *   *
            *                                                     *
            *    A monthly guide to BITNET servers and services   *
            *******************************************************

                      Volume 1 Number 2  -  August 1986

                     Editor: Chris Condon BITLIB@YALEVMX

                                * Contents *

            Bitnotes ............................................ 1
            Instant Insanity by Jeff Kell ....................... 3
            Relay Growth ........................................ 6
            New Mailing Lists ................................... 7
            The VAX Toolbox ..................................... 7
            /Links .............................................. 8
            The NETSERV User Directory Services ................. 8
            New List Servers ................................... 10
            Spotlight Server: UTCSERVE@UTCVM ................... 12
            Feedback ........................................... 13
            Policies ........................................... 14

                  __________________________________________
                 /                                         /[
                /__________________________________________[/
                ]
                ]        ___________________________________
                ]       ]  ]                               /[
                ]       ]  ]_______________________________[/
                ]       ] /
                ]       ]/__________________________________
                ]                                          /[
                ]__________________________________________[/


            A complete  list of servers  and services is  available
            from any  NETSERV file server as the  file named BITNET
            SERVERS.  News,  article submissions,  additions to the
            list of servers and services, subscription requests and
            letters to the editor should be sent to BITLIB@YALEVMX.
            Subscribers  are  also  sent  BITNET  SERVERS  updates.

            Printing this file:  VM users  can print  this magazine
            by first copying or renaming it to NETMONTH LISTING and
            then printing it with your local file printing command.

            -------------------------------------------------------

            FuzzyBytes Electronic Publishing  "Because We're Here."

1

                                                                       Page 1

   *************************************************************************
  * Bitnotes                                                        Issue 2 *
  ***************************************************************************

             "Never underestimate the power of human stupiditiy."
                                               - Robert A. Heinlein

  Ignorance  is bliss, or so they say.  That may not be applicable to BITNET,
  for here  ignorance  usually  spells  Trouble  (yes,  with a  capital 'T').
  Ignorance may  be as harmless  as not  knowing  how to use a file server or
  as harmful as requesting 125 files  from a  file  server within  the course
  of three minutes. Certainly, this  is not bliss.  Not for  the poor guy who
  doesn't know  what is  going on, or  for  the  person  wondering  why it is
  taking so long for those 125 files to arrive.

  Discipline  begins at home, or  so they say.  Likewise, education on how to
  use  BITNET  servers and services begins  at the home node.  I have gotten
  some mail about  this, requests  for tips and information.  And  while I am
  not  a node administrator by any means, I might be  able to  get away  with
  listing  these suggestions.

  1. When in doubt, don't.

     Allegedly  common sense will tell you it  will require a lot more effort
     to fix something you have  done wrong than it will to do it right in the
     first place.  If you don't understand how  to use a server  or  service,
     ask somebody who does, or refer to the local documentation.  Which leads
     to:

  2. Keep documetation on how to use the servers and services at your node.

     Keep it in a  really obvious place too, and  update it  frequently.  One
     helpfile about  CSNEWS on a public  disk  is a lot  safer than ten users
     with copies of their own (and  a lot more  efficient  to  boot!).  Store
     some explanations  on what each type of server  does (i.e What is a file
     server? What does  it do? How do  you use it?)  You might even go as far
     as printing a local BITNET users guide  (although  it would  have  to be
     pretty general with the way things change).

  3. Have a BITNET user consultant at your node.

     There  is not much  sense in  the blind  leading the  blind, so  this is
     particularly helpful.  You might  want  to make this  person responsible
     for keeping  the documentation updated.

  4. Develop some usage guidelines, and stick to them.

     Yes, there may be some bad apples at your node. Have some sort of policy
     to deal  with these people.  On  the other hand, some people just  don't
     know any better, so post some guidelines on what is acceptable  and what
     isn't.  You'd be surprised  what some may  do unless you tell  them they
     shouldn't.   I think  (my opinion  only) that  a policy  that deals with
     individual abuses will have a greater affect on those-who-would-be-bad.


1

                                                                       Page 2


  Fine.  Those are all wonderful suggestions  on how to  prevent  yourelf and
  others from  doing something wrong.  A  more positive  approach might be to
  list some things you can do RIGHT.  From this  end of the  picture it seems
  that one of the rightest  things you can do is offer services to the BITNET
  community.

  This  doesn't  mean  that you  have to run  a file  server  or  produce  an
  electronic  magazine. Perhaps you don't have the time or resources for that
  sort of thing.  That doesn't  mean  you can't  do something with a slightly
  lower profile.  Some suggestions for students and administrators alike:

  1. Form a local BITNET user's group.  It doesn't  have  to be  large  to be
     effective  (although  it  probobly  helps).  Not  only  can  you promote
     the responsible use of the network, it makes good resume material, too!

  2. Write an article for one of the electronic magazines.

     You must have some thoughts about what  is  happening in BITNET.  If ONE
     user at  each node  wrote ONE  article in ONE year there would be enough
     material to make the monthlies go weekly.  Why not  be that one and give
     it a try?

  For  those of you who might want to take on the responsibilbity of offering
  a  full  scale service,  like a file  server  or  mailing  list,  here  are
  some considerations to take into account before you get in too deep. Try to
  approach it as  if you were running  a business,  where your service is the
  product that you want to sell:

  1. Is there a need for this service?

     Example:  If Joe Dokes is already  running a  file server for people who
     are interested in Chemistry, is there a need for a second one?  Or maybe
     there is a server like that but you think you could do a better job.

  2. Are there enough people interested in what you want to do?

     Example:  If you want to run a mailing list for people  concerned  about
     the  social implications of knitting, make sure there are  enough people
     interested in that sort of thing.

  3. Do you have the resources to produce this service?

     Remeber, time is your most valuable resource.  Do you have enough of it?
     If you want  to produce a  weekly  electronic magazine, do you think you
     can really put one  out regularly?  Or  will you  slack off  after three
     weeks? And what will happen to the magazine when you leave the network?

  4. Does your SYSTEM have the resources to produce this service?

     If  your system has a  lot of people  using  mega-cpu  maybe  running  a
     file server there isn't such a good idea.


1

                                                                       Page 3

  In this issue we have, to put it lightly, a lot of good stuff.  First  off,
  we have  an article  written by  the author  of Relay, Jeff Kell.  It sheds
  some light  on the directions  Relay is  taking, as  well as answering some
  prickly and  not-so-pricky questions.   As a companion to that, I drew up a
  chart showing the Relay growth in the past year...

  DON'T PANIC!  I have  included a lot of non-Relay articles, too.  There are
  plenty of new mailing lists, list servers, and user databases.  In addtion,
  the  Feedback  column  makes  it's  first  appearance  in  it's  soon-to-be
  traditional spot on the last page.

  Meanwhile, I  have made a few obvious cosmetic changes to NetMonth, as well
  as a feeble attempt to insert some page breaks. Who has the time to SCRIPT?

  Off we go...


   *************************************************************************
  * Instant Insanity - by Jeff Kell  JEFF@UTCVM                             *
  ***************************************************************************

     Instant Insanity -or- Why I Should Have Anonymously Written Relay :-)


  Several  years ago, I  discovered  'chat' machines.  Ahhh,  the old days of
  Billy,  Missing  Link,  LateHack  and  EarlyHack,  Castle,  WorldNet,  etc.
  And  shortly  thereafter,  about February  1985  I  seem to  recall,  Henry
  Nussbacher's  infamous paper  concerning  the dangers of  chat  machines to
  the network  was circulated  to contacts,  managers,  and administrators of
  practically every site in the network.  And boom, the party was over, or at
  least rather well pooped.

  There  were many  valid points to  the paper.  There are dangers to the old
  centralized  chats.  If you  don't understand  them, you  can read about it
  in RELAY INFO  (the /info  command) or  elsewhere,  I don't  want to repeat
  them  again here.  The bottom  line  remained:  centralized  chats were bad
  business.   Management  in  general  (contacts,  administrators,  technical
  people)  developed a  bad taste  for "chatting", and  most of it was put to
  a halt.  Others went  underground,  and when  discovered  and exposed, only
  served to increase management distaste for the whole concept.

  I began  working on  Relay around  March of 1985, and sometime thereafter a
  Relay here  at UTCVM  (Version 0.03  or so) successfully  linked to a Relay
  at YALEVM  and the  distributed Relay  system was born.  Growth  was  slow,
  as the  last thing  management  wanted to hear  about was  another  "chat",
  and it  was hard  to be granted  a brief  hearing, let alone get volunteers
  for  beta  testing.  Add  to this the  problems of  testing and debugging a
  program of  this size spread  out across  three  continents, and it was not
  a pretty picture; but eventually things began to stabilize.

  The  biggest  "boost" to Relay  came when some  management switched over to


1

                                                                       Page 4

  our side,  although granted  with  considerable  caution.  When  Relay  was
  being  considered for  becoming  "official" at Yale,  Jim Owen  and Phillip
  Long sent  me a list  of their  concerns to  insure that Relay would not be
  recreating  the same problems  the older chats  had.  Thus the first set of
  statistics,  limitations, and  restrictions were  imposed in  an  effort to
  make Relay "legitimate".

  Currently,  several members  of the Bitnet Executive Committee are directly
  involved  with Relay.  The committee  as a whole  has discussed  Relay more
  than  once and it  is still  currently  under study;  although we have done
  a great deal  to improve  the technical  aspects of  Relay  in terms of the
  network  load and  CPU requirements,  there is  still a large  concern that
  Relay  serves no  "practical"  purpose.  Admittedly,  it is hard  to make a
  point  in my favor  when you have  management issuing a "/who" to Relay and
  finding users like "SuperStud", "NeedSex", and "Cuddles".

  Management complains that Relay is not restrictive enough.  Users  say that
  Relay is too restrictive.  And guess who *receives* the complaints?

  We are  currently  drafting a  "Usage Guidelines" statement for Relay to be
  presented  to the  Executive Committee.   It  *may* pass,  in which case we
  will be  accepted once  and for all.  If it  does, you  *may* not like what
  it contains;  it is more  restrictive  than  we  currently  are  enforcing.
  But it will be a final word, and hopefully final peace.

  The new policy calls for such things as:

     * Restricting  public users  (as it  is  now) to  channels 0-9 and still
       enforce service areas, quiesced periods, limits, etc.

     * Creating  a "full  access"  user class  which can  only be  granted by
       the host  Relay's  master  operator.  This  class of user  can use any
       channel  at any time,  but *only* for  *practical*  purposes, ie., for
       real conferencing and not recreation.

  I personally think  it is a bit  harsh; I'm  not out  to "get" anyone.  But
  it would  be of enormous  value to  have the  Relay  program  finally reach
  a  "legitimate"  status.   Please don't  rush off  to mail  your flames too
  early either;  remember it  is  precisely  what Relay  has  shown itself to
  be  that brought this on  in the  first  place.  For  example, in answer to
  the numerous complaints I have had in various areas:

  * "Why  can't I  use  the  BLAHBLAH Relay  instead of  the one I'm supposed
     to use if I want to?"

     Relay  is supposed  to  REDUCE  network  traffic.  If  you  use  a Relay
     that  is farther  away, you  will  only  INCREASE  traffic.  Since users
     would  not do  this on  their  own for  whatever  reason, Relay enforces
     this now.

  * "I was  warned/banned  about scanning  channels; what's wrong with that?"

     Private  channels  are just  that -- private.  You can /msg the user and
     ask to b e invited, but  you  don't just drop in.  In addition, it takes
     a certain  amount of  overhead to process the channel change and migrate
     that change to the other relays.



1

                                                                       Page 5

  * "Why am I supposed to sign up with my real name?"

     If you  aren't honest  enough to  use your real  name, or at least use a
     name  that looks  real, what  kind of  practical/legitimate  use  are we
     supposed  to expect  from you?  Relay  does not have to be stone serious
     all the time, but that is stretching things a bit.

  * "My Relay is quiesced, why can't I use another one?"

     Relays  are quiesced  to reduce  network  load during  prime  time.  The
     original  Executive  Committee  request was  to quiesce  ALL Relays from
     8:00 AM  until  6:00 PM;  but thus far only  the central  Relays in high
     traffic  areas are  quiescing  at all.  Granted,  when Bitnic  is in its
     quiesced  state, Europe  is cut  off from  the  states,  and  the CUNYVM
     side separated  from the  PSUVM side;  but if  you use  a  Relay  on the
     other  side of  the quiesced  one, your  messages  will pass through the
     node or  link  in  question,  generating  precisely  the load  that  the
     quiesce was trying to prevent.

  The  list goes on,  but these  are the most frequent.  I also get them from
  the other side of the fence:

  * "Why is this  user signed on to Finland's Relay?"

     They  are at  one of  those  new nodes  that didn't  get in  the service
     area;  I'll  ask them  to stay  where  they  are supposed  to be  but it
     can't  make  them until  I get  the updated  service  areas  shipped  to
     Finland.

  * "Our  Relay was  using 40%  of the  CPU last  night and  I forced  it off
     the  system... if  you can't  fix this  thing I'm  going to have to take
     it off for good"

     Sorry, I  examined your  console  log and  found a user was running some
     sort  of exec  to scan  private  channels;  it was  doing repeated /chan
     and  /who commands  and  caused  a big  message  backlog.  It wasn't the
     Relay's fault; maybe you should ban that user.

  * "I  signed on  to the  Relay last  night to  try  it for  myself... there
     were  14 people  on channel  one trying  to get a date and some guy that
     was  sending  ghostbuster  pictures;  a /stat showed the CPU was getting
     high and  our RSCS  was starting  to get a  file  backlog... is that all
     Relay is doing for us?"

     (No answer)

  Get the idea?


1

                                                                       Page 6

   *************************************************************************
  * Relay Growth                                                            *
  ***************************************************************************

  I spend some of  my time trying  to figure  out where  BITNET  services are
  going, and in  the process I came up with  this cute little  graph.  It  is
  supposed to represent the growth of  the Relay conference  machine  network
  from  May 1985 until July 1986.  While some have described  Relay growth as
  sluggish (or  something to that  affect), none of  the other  services grew
  quite the way this one did.



     N   35 -                                                           OO
                                                                   OOOOOOO
     U                                                      OOO OOOOOOOOOO
                                                           OOOOOOOOOOOOOOO
     M                                                    OOOOOOOOOOOOOOOO
         30 -                                            OOOOOOOOOOOOOOOOO
     B                                               OOOOOOOOOOOOOOOOOOOOO
                                                    OOOOOOOOOOOOOOOOOOOOOO
     E                                 OOOOOOO     OOOOOOOOOOOOOOOOOOOOOOO
                                     OOOOOOOOO    OOOOOOOOOOOOOOOOOOOOOOOO
     R   25 -                       OOOOOOOOOO    OOOOOOOOOOOOOOOOOOOOOOOO
                                  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                               OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                               OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     O                         OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
         20 -                  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     F                         OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                             OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                             OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                           OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     R   15 -              OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                           OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     E                     OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                           OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     L                     OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
         10 -              OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     A                    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                        OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     Y                OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
         5  -         OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
     S                OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                      OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                      OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
         1  -   OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
                     ]    ]    ]    ]    ]    ]    ]    ]    ]    ]    ]
                     5    10   15   20   25   30   35   40   45   50   55

                               N U M B E R   O F   W E E K S

1

                                                                       Page 7

   *************************************************************************
  * New Mailing Lists                                                       *
  ***************************************************************************

  CA@THINK.COM

     Mailing  list  for  the  exchange   of  information  on all  aspects  of
     cellular automata and their applications.

     All  requests  to be  added to  or deleted  from  this  list,  problems,
     questions,  etc., should be  sent to CA-REQUEST@THINK.COM.

     Coordinator: Bruce Nemnich 

  INFO-IDL@SEI.CMU.EDU

     Discussion  of  issues  relating  to  IDL  (the  Interface   Description
     Language) and IDL-like technologies.

     All  requests to  be  added  to  or deleted  from  this  list,  problems,
     questions, etc., should be sent to INFO-IDL-REQUEST@SEI.CMU.EDU.

     Coordinator: Don Stone (ds@SEI.CMU.EDU)

  INFO-IRIS@SUMEX-AIM.STANFORD.EDU

     This  discussion list focuses on Silicon Graphics Iris  workstations and
     software. Its purpose is to stimulate communication  and sharing between
     computer  science  research  groups  that are using or are interested in
     these machines.

     All  requests  to  be added  to or  deleted  from  this  list,  problems,
     questions, should be sent to Info-Iris-Request@SUMEX-AIM.STANFORD.EDU.

     Coordinator: John Brugge 

  Mail-Zilog 

     A self-help group to provide communications among  Zilog  users.  Topics
     include problems with  Zeus, fixes,  portability  problems, availability
     of ported  software and  exchange of programs on Zilog compatible media.
     Open to  both end users  and systems  houses, but all  should be able to
     cope with the phrase Zilog Brain Damage with some degree of equanimity.

     All  requests  to be  added to  or  deleted  from  this  list, problems,
     questions,  etc., should be sent to cbmvax!mail-zilog@SEISMO.CSS.GOV.

     Coordinator: George Robbins 


   *************************************************************************
  * The VAX Toolbox                                                         *
  ***************************************************************************

  Bob Boag  (BOAG@MUVMS1) is  the editor of a new electronic magazine for VAX


1

                                                                       Page 8

  users.   This  newsletter  is  published  monthly,  and  is  loaded full of
  articles  about  DCL (Digital  Command  Language),  The  Librarian,  System
  Services,  Run-Time  Library Routines, the EDT editor, JNET, and much more.
  If  you, or  anyone  you know  would  be  interested  in receiving  the VAX
  Toolbox, send electronic mail BOAG@MUVMS1.


   *************************************************************************
  * /Links                                                                  *
  ***************************************************************************

  Thanks  once again  to Jeff Kell for his  news about yet another new Relay.
  This one is RELAY@BEARN, The mainframe of the National Scientific Research
  Fund, Brussels, Belgium.


   *************************************************************************
  * The NETSERV User Directory Services                                     *
  ***************************************************************************

  The User  Directory Services  of  NETSERV (abbreviated: UDS) provide BITNET
  users with  the ability to  register themselves  in the directory (ADD), to
  change (REP) or delete (DEL) their registration and to search the directory
  for other users (GET or FIND).

  NETSERV provides  some  programs/execs to  be run  at the  user side  which
  make  registration  and searching simple.  Unfortunately they only work for
  VM nodes.

  These are (for VM):  NETNAMES EXEC    (user registration and search)
                       UDSLIST  EXEC    (list updates)

                       They are available from any NETSERV file server.

  Those of you  who can run those  programs don't  need send your commands in
  files as described below.  Those of you at VAX nodes or nodes that can only
  send and  receive mail  and files may be  interested in the way to send the
  commands via file:

  UDS ADD

         This command can be used to create an entry in the User Directory of
         your country. The  data you  send with  must  be a NAMES entry.  The
         entire file you send should look as follows:

            UDS ADD
            :userid.XXXXXXXX  :node.YYYYYYYY
            :name.Firstname Lastname
            :phone.phone number (e.g. +33 (1) 514-31-00)
            :addr.institute name; city; country
            :descr.job title; activities; interests; etc.

            Minimum required data is: userid, node and name.

         If an entry for your userid/nodeid  already  exists your ADD request
         will  be rejected.  If you want to replace an existing entry use the
         UDS REP  command.



1

                                                                       Page 9

  UDS DEL

         This command  can be used to delete your entry in the User Directory
         of your  country. There is  no other data or information required to
         perform this function.


  UDS FIND   search arguments

         This  command  allows all  users to  search  the User Directory  for
         information  about other users in  the country where this NETSERV is
         running. The search result is one message  line per  entry  matching
         the  search  request.  The   message  lines  contain  the  following
         information:

            entry-nbr: name (userid @ nodeid) phone

         These  messages will  either be  sent as  immediate messages  if the
         arrived  as a message and the response isn't more  than 20 lines, or
         the  response is sent  as a Note.  The  maximum  number  of  entries
         returned is 100. A message indicates whether there are more than 100
         entries  matching your  search request. You may specify more precise
         search arguments to limit the number of matches.

         The format of the search arguments must be:

            :tagname searchvalue  ...

            where :tagname may be one of the following:

                   :nick  (specify entry number as  searchvalue. If  :nick is
                          specified, all other search arguments are ignored.)

                   :userid       :node        :name

                   :phone        :addr        :descr  (description)

         "searchvalue" can  be any character  string that you want to find in
         the specified tag.

         The search  will only be successful  if the specified strings appear
         appear in the appropriate tags of one or more  user directory entry.
         Case (upper/lower) will be ignored.


  UDS GET    search arguments

         see UDS FIND


  UDS REP

         This command can be used to replace your entry in the User Directory
         of your country. The data you send with must be  a NAMES entry.  The


1
                                                                      Page 10

         entire file you send should look as follows:

            UDS REP
            :userid.XXXXXXXX  :node.YYYYYYYY
            :name.Firstname Lastname
            :phone.phone number (e.g. +33 1 514-31-00)
            :addr.institute name, city, country
            :descr.job title; activities; interests; etc.

            Minimum required data is: userid, node and name.

         It is strongly  recommended not to  use special letters  of national
         character  sets and to avoid certain special characters.  the reason
         behind this  is that other  people  (with different keyboards) would
         not be able to type appropriate search arguments and  your entry may
         not be displayed correctly on different terminals.  The following is
         a list of all  characters  which seem to  be common to all keyboards
         which seem to be common to all keyboards and can be used:

            a-z  A-Z  0-9  space  & + - * / = % . , ;  ( ) _

         You should not use a colon (:) since this may be  interpreted as the
         start of a new field.


   *************************************************************************
  * New List Servers                                                        *
  ***************************************************************************

  As  the revised list  processor code continues  to be  tested and improved,
  more new LISTSERV sites have sprung up.  These are listed below, as well as
  the  lists they  maintain.  All of  these servers  will respind to the HELP
  command sent as a message.

  Distribution lists from LISTSERV at UIUCVMD

  AMIGA-L       Amiga discussions
  APL-L         APL (language) discussions
  ATARST-L      Atari ST discussions
  BEER          Wednesday Beer Drinkers Group
  C-L           C (language) discussions
  CMSR4-L       CMS release 4 discussions
  CPR4-L        CP release 4 discussions
  GCS-L         GCS Working Group
  IBMPC-L       IBM PC discussions
  INFOKERM      Info-Kermit Digest distribution
  LSTSRV-L      Revised LISTSERV discussion
  MAC-L         Macintosh discussions
  MODULA-L      Modula-2 (language) discussions
  PASCAL-L      Pascal (language) discussions
  PL1-L         PL1 (language) discussions
  REXX-L        REXX (language) discussions
  TCP-IP-L      TCP IP discussion from SRI-NIC
  TCPIP-L       TCP IP Bitnet discussions
  UTS-L         UTS discussions
  VMAINT-L      VM Maintenance Discussion Group
  VMVTAM-L      VM VTAM Working Group
  VM3800-L      VM 3800 printer discussions


1

                                                                      Page 11

  Distribution lists from LISTSERV at BNANDP10

  BEARNNAD      Forum for Belgian NAD's
  CHIMIE        Contact utilisateurs du groupe Chimie
  GUEST         Contact utilisateurs invites du SCF
  LIEGE         Contact utilisateurs du groupe Liege
  LOCAL         Contact utilisateurs locaux du SCF
  LOUVAIN       Contact utilisateurs du groupe Louvain
  PHYSIQUE      Contact utilisateurs du groupe Physique
  REMOTE        Contact utilisateurs exterieurs du SCF
  SCFINFO       L'INFORmation Sans Coup Ferir
  SOLVAY        Contact utilisateurs du groupe Solvay
  ULB           Contact utilisateurs du groupe ULB

  Distribution lists from LISTSERV at RICE

  $$INFOPC      Info-PC subscription list
  IBM-MAIN      IBM mainframe subscription list
  MAILBOOK      MAIL/MAILBOOK subscription list
  PC-TOKEN      PC token-ring subscription list
  POSTMAST      Postmaster list
  SUGGEST       Suggestion box

  Distribution lists from LISTSERV at TAMCBA

  COMGROUP      Communications Committee
  CONTACTS      TAMU Machine Contacts
  DIRECTOR      Director Notify List
  INFORM        TANU Inform List
  TAMDPEND      TAMU Depend BITnet Links

  Distribution lists from LISTSERV at FINHUTC

  APPLICAT      Bitnet Applications
  ARPABBS       Arpanet Bulletinboards
  ARPALIST      List of Lists
  BITLIST       NetMonth magazine
  CAE           CAE-projektin kuulumisia
  CLUB          Club Magazine
  CRTNET        Communications Research and Theory Network
  EARNTECH      EARNTECH List
  FSFNET        Fantasy and Science Fiction Network
  FUTURE-L      Future of BITNET
  GNUEMACS      Gnu-Emacs bugs and info
  IBM-NETS      IBM networking
  IBM7171       Protocol converters
  INFO-GNU      Gnu information
  INFONETS      General network forum
  INFO16        Atari ST users forum
  JAPAN         Info-Japan
  LINKFAIL      Link failure announcements
  MAIL          Mail standards in BITNET
  NETSTD        Networking standards in BITNET
  NIHONGO       Nihongo
  NUTS          Nutworks magazine


1

                                                                      Page 12

  PROLOG        Prolog digest
  PROLOG-H      Prolog hackers digest
  PSCRIPT       Postscript forum
  PSYCHNET      Psychology newsletter
  REXX          REXX user's forum
  RSCSMODS      RSCS modifications list
  SCHEME        Scheme programming language
  SERVERS       Server developers forum
  SFLOVERS      Sci-Fi Lovers
  TEXHAX        TeX hackers
  TRANSFER      Bitnet file transfer
  USRDIR        User directories
  X400          X400 standard in BITNET
  IKD           Info-Kermit Digest


  Distribution lists from LISTSERV at TAMVM1

  RSCSMODS      The RSCS modifications list
  TAMSEC-L      TAM* RSCS Security mod distribution


  Distribution lists from LISTSERV at OREGON1

  NEWS-L        News
  SAS-L         SAS users list
  SPSSX-L       SPSSX users forum
  STATS-L       General statistics at UO


   *************************************************************************
  * Spotlight Server:  UTCSERVE@UTCVM                                       *
  ***************************************************************************

  UTCSERVE@UTCVM is a  file server at University of Tennessee at Chattanooga.
  It will respond to the following commands:

  HELP   -  where  is HELP, DIR or SENDME. You will be sent
                     more information on how to use a particular command.  If
                     the    parameter is  omitted  a list  of  valid
                     commands is sent.

  DIRectory       -  You  will be  sent a list  of files  that are  currently
                     available to all UTCSERVE users.

  SENDme   -  where  is  the filename  and filetype of the file
                     you want to be sent to you.

  *PLEASE NOTE*   -  UTCSERVE sends you  files in  the SENDFILE format.


1

                                                                      Page 13

   *************************************************************************
  * Feedback                                                                *
  ***************************************************************************

  Date:     Mon, 21-JUL-1986 09:52 EST
  From:     Jason J. Lane 
  To:       BITLIB@YALEVMX


  Chris,
        I'd like to say first off that I like the new format of Bitlist,  but
  why the  name  change?  I do  like the  new title  Netmonth  but  I thought
  Bitlist was a better name. Also I didn't realize you are going to send  the
  Servers list out  every month also.  Why not just  send updates  within the
  Netmonth list instead of sending out a huge file? I look forward  to future
  issues  and hope you  can find  someone  to maintain  all of this after you
  graduate.

                                                        Scantily,

                                                        Jason Lane
                                                        JJL8733@RitVaxC


  >> Thank you for your comments. I made the name change since this  magazine
  really isn't the Bitlist. Bitlist was originally  just a LIST, no Bitnotes,
  no articles. NetMonth is really an expanded Bitnotes column, and not a list
  of anything.  (At least that was  the reasoning I  used at the time).   The
  name NetMonth is also sufficiently nondescript as to let me include a wider
  range of material  than  in  Bitlist.  I  originally  wanted  to  call this
  rag "Networker",  but  that would have lead lead to filenames like NETWRKER
  1986AUG, which look silly. I was also tired of getting letters where people
  were  asking for  a subscription  to BITLIB.  There  is no way  to  confuse
  NetMonth with my userid!!

  I send out  the updates in one huge file because I don't trust anybody else
  to edit  BITNET SERVERS. :-) But  seriously,  I would  rather send  out the
  complete updated  file than risk having half-updated or incorrectly updated
  lists out there.  This way, I'm the one to blame!

  As for finding someone to keep this up after I  graduate, I am hoping to go
  on  doing this  when I find  myself in  the Real World.  That  might not be
  a realistic hope, but this is, after all, my leisure-time activity.


1

                                                                      Page 14

   *************************************************************************
  * NetMonth Policies                                                       *
  ***************************************************************************

  If  you have questions or comments about BITNET or NetMonth  that you would
  like printed here,  mail your letter to BITLIB@YALEVMX.  Make sure that you
  specify in the "Subject:"  header or somewhere in the letter that it is for
  the NetMonth  letters  column. This  doesn't mean that your  letter will be
  printed, but it helps.  Your opinion counts!

  Article Submissions:  The  only requirements for NetMonth articles are that
  they be informative,  interesting, and  deal with  BITNET  services (or any
  other  good BITNET  related topics).  The  editor  will  inform  you of any
  changes to your writing and will submit them  for your  approval, deadlines
  permitting.  Send your articles to BITLIB@YALEVMX.

  ---------------------------------------------------------------------------

  FuzzyBytes Electronic Publishing                      "Because We're Here."